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DATA COMMUNICATION SYSTEM, DATA COMMUNICATION METHOD, 
DATA COMMUNICATION APPARATUS AND DIGITAL INTERFACE 



BACKGROUND OF THE INVENTION 
5 Field of the Invention 

The present invention relates to a data 
communication system, a data communication method, a 
data communication apparatus and a digital interface, 
^5 and, more particularly, it relates to a network in 

in 10 which communication is effected at a high speed while 
mixing information data (including image data) and 

ry 

command data, and a communication protocol applicable 

to such a network. 

Related Background Art 
^0 15 In the past, among peripheral equipments for a 

* : Q personal computer (referred to as "PC" hereinafter), 

hard discs and printers have been used most widely. 

Such a peripheral equipment has been connected to the 

PC via a multi-purpose digital interface such as an 
20 exclusive I/O interface or an SCSI (small computer 

system interface ) . 

On the other hand, recently, AV (Audio/Visual) 

equipments such as digital cameras, digital video 

cameras or the like has also been noticed as one of the 
25 peripheral equipment for the PC. Such an AV 

(Audio/Visual) equipment has also been connected to the 

PC via an exclusive interface. 
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Fig, 1 is a view showing a conventional 
communication system including a PC and AV equipments . 

In Fig. 1, the communication system includes an AV 
equipment (digital camera) 101, a PC 102 and a printer 
103. 

The digital camera 101 includes a memory 104 for 
compressing and storing a photo- taken image, a decoding 
unit 105 for effecting decoding by expanding the 
compressed image data stored in the memory 104, an 
image processing unit 106, a D/A converter 107, a 
display unit 108 comprised of an EVF, and an exclusive 
digital I/O unit 109 for connecting the digital camera 
101 to the PC 102. 



v The PC 102 includes an occlusive digital I/O unit 
110 for connecting the PC m)2 to the digital camera 
101, an operation unit 1Y1 including a keyboard and a 
mouth, a decoding unit/112 for effecting decoding by 
expanding the compressed image data, a display 113, a 
hard disc 114, a memory 115 such as a RAM, an MPU 116, 
a PCI buss 117, And an SCSI interface 118 for 
connecting the/PC 102 to the printer 103. 

The printer 103 includes an SCSI interface 119 for 
connecting the printer 103 to the PC 102, a memory 120, 
a printer head 121, a printer controller 122 for 
controlling an operation of the printer 103, and a 
driver 123. 

In the conventional communication system, the 
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digital interface (digital I/O unit 109) of the digital 
camera 101 and the digital interface (SCSI interface 
119) of the printer 103 has no interchangeability , so 
that the digital camera and the printer could not be 
interconnected directly. Thus, for example when a 
still image is desired to be sent from the digital 



camera 101 to the printer 103, the data had to be 



passed through the PC without fail. 
3 Further, in the conventional exclusive interface 

£ jj 

H 10 and/or SCSI interface, particularly when large capacity 

is? 

data such as a moving image or a still image of the AV 



equipment is processed, there arose various problems 
that a data transfer rate becomes low, that a fat 
communication cable is required for parallel 

15 communication, that the number and kind of peripheral 

equipments capable of being connected are limited, that 
a connection system is limited and that real time data 
transfer cannot be effected. 

As one of next generation high speed and high 

20 performance digital interfaces for solving the above 
problems, IEEE (The Institute of Electrical and 
Electronics Engineers, Inc. ) 1394-1995 Standard is 
already known. 

The digital interface based upon the IEEE 1394- 

25 1995 Standard (referred to as "1394 interface" 
hereinafter) has the following features: 
(1) A data transfer speed is fast. 
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(2) A real -time data transfer system (i.e., 
isochronous transfer system) and an asynchronous 
transfer system can be supported. 

(3) A connection construction (topology) having 
5 high degree of freedom can be fabricated. 

(4) A plug-and-play function and a hot-line 
insertion/withdrawal function are supported. 

However, in the IEEE 1394-1995 Standard, although 

O 

IP physical and electrical constructions of connectors and 

lu 

in 10 two fundamental data transfer systems are defined, 

=g there was no definition regarding how to transmit and 

ill 

|.H receive what kind of data through what kind of data 

s;3 format on the basis of what kind of communication 

j,I protocol . 

15 Further, in the isochronous transfer system based 

upon the IEEE 1394-1995 Standard, since response to 
outgoing packets is not stipulated, it is not ensured 
whether each isochronous packet is positively received. 
Accordingly, when it is desired that continuous plural 
20 data are positively transferred or when it is desired 
that one file data is positively transferred while 
dividing it into plural data, the isochronous transfer 
system could not be used. 

Furthermore, in the isochronous transfer system 
25 based upon the IEEE 1394-1995 Standard, even when there 
is vacancy in transfer band, the total number of 
transmissions is limited to sixty-four. Thus, when it 
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is desired that; many transmissions are effected with 
smaller transfer bands, the isochronous transfer system 
could not be used. 

In addition, in the IEEE 1394-1995 Standard, if 
5 bus reset is generated in response to ON/OFF of a power 
source for nodes or connection/disconnection of the 
node, data transfer must be interrupted. However, in 
the IEEE 1394-1995 Standard, if the data transfer is 
interrupted due to the bus reset or error in 
f;R 10 transmission, it could not be known what kind of data 

* : y contents are lost. Further, in order to restore the 

h u 

In interrupted transfer, very complicated transmission 

p sequence was required. 

11 Incidentally, the bus reset refers to a function 

.S 15 for automatically effecting recognition of new topology 

and the setting of address (node ID) assigned to each 
node. In the IEEE 1394-1995 Standard, this function 
can provide the plug-and-play function and the hot-line 
insertion/withdrawal function. 
20 Further, in the communication system based upon 

the IEEE 1394-1995 Standard, communication protocol in 
which (although real time ability is not required) 
object data (for example, still image data, graphic 
data, text data, file data, program data and the like) 
25 having relatively large data amount are continuously 
transferred while dividing such data into one or more 
segment data was not proposed concretely. 
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Lastly, in the communication system based upon the 
IEEE 1394-1995 Standard, communication protocol in 
which data transmission between plural equipments is 
achieved by using a communication system for 
5 broadcasting data in an asynchronous transferring was 
not also proposed concretely. 

SUMMARY OF THE INVENTION 
^ An object of the present invention is to solve the 

10 above-described problems. 

Another object of the present invention is to 
provide a technique in which object data not requiring 
real time ability can be transferred continuously and 
positively in a data transmission system, a data 
15 transmission method and a data transmission apparatus. 

A further object of the present invention is to 
provide a technique in which, even when a logical 
connection relationship (i.e., connection ) between a 
source node and one or more destination nodes is set by 
20 a plurality of controllers, connection set by other 
controller can easily be discriminated, thereby 
achieving more efficient data transmission, in a data 
transmission system, a data transmission method and a 
data transmission apparatus. 
25 A still further object of the present invention is 

to provide a technique in which, even when a plurality 
of different logical connection relationships (i.e., 
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connections ) between a source node and one or more 
destination nodes are set, each connection can easily 
be discriminated, thereby achieving more efficient data 
transmission, in a data transmission system, a data 
5 transmission method and a data transmission apparatus. 

As a preferred embodiment for such objects, the 
present invention discloses a data communication system 
comprising a controller for setting a logical 
connection relationship different from that set by 

10 other controller, between a source node and one or more 
destination nodes, a source node for transferring 
object data divided into one or more segments in an 
asynchronous transferring by using the logical 
connection relationship, and one or more destination 

15 nodes for receiving the object data transferred from 
the source node in the asynchronous transferring. 

As another embodiment, the present invention 
discloses a data communication system comprising a 
controller for setting a logical connection 

20 relationship different from that set by other 

controller, between a source node and one or more 
destination nodes, a source node for broadcasting 
object data divided into one or more segments by using 
the logical connection relationship, and one or more 

25 destination nodes for receiving the object data 
broadcasted from the source node. 

As a further embodiment, the present invention 
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discloses a data communication system comprising a 
controller for setting new logical connection 
relationships between a source node and one or more 
destination nodes, a source node for transferring 
5 object data divided into one or more segments in an 

asynchronous transferring by using one of the logical 
connection relationships, and one or more destination 
nodes for discriminating the logical connection 

.CSS. 

['j* relationship and for receiving the object data, 

iff 10 As a still further embodiment, the present 

*~ invention discloses a data communication system 

is : i 

llj: comprising a controller for setting new logical 

]; m connection relationships between a source node and one 

M 

i'U or more destination nodes, a source node for 

v3 15 broadcasting object data divided into one or more 

sfl segments by using one of the logical connection 

relationships, and one or more destination nodes for 
discriminating the logical connection relationship and 
for receiving the object data. 
20 As a further embodiment, the present invention 

discloses a data communication system comprising a 
source node for successively transferring object data 
divided into one or more segments in an asynchronous 
transferring by using one of a plurality of logical 
25 connection relationships set between a plurality of 
nodes, and one or more destination nodes for 
discriminating one of the plurality of logical 
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connection relationships and for receiving the object 
data. 

As a still further embodiment, the present 
invention discloses a data communication system 
5 comprising a source node for successively broadcasting 
object data divided into one or more segments by using 
one of a plurality of logical connection relationships 
set between a plurality of nodes, and one or more 
;=3 destination nodes for discriminating one of the 

in 10 plurality of logical connection relationships and for 

*.S receiving the object data, 

f'U 

Ln As a further embodiment, the present invention 

p discloses a data communication method comprising steps 

11 of setting a logical connection relationship different 

^ 15 from that set by other controller, between a source 

~ node and one or more destination nodes, transferring 

object data divided into one or more segments in an 
asynchronous transferring by using the logical 
connection relationship, and receiving the object data 
20 transferred in the asynchronous transferring. 

As a still further embodiment, the present 
invention discloses a data communication method 
comprising steps of setting a logical connection 
relationship different from that set by other 
25 controller, between a source node and one or more 

destination nodes, broadcasting object data divided 
into one or more segments by using the logical 



connection relationship, and receiving the object data 
broadcasted . 

As a further embodiment, the present invention 
discloses a data communication method comprising steps 
5 of setting new logical connection relationships between 
a source node and one or more destination nodes, 
transferring object data divided into one or more 
segments in an asynchronous transferring by using one 
of the logical connection relationships, and 

10 discriminating the logical connection relationship and 
receiving the object data. 

As a still further embodiment, the present 
invention discloses a data communication method 
comprising steps of setting new logical connection 

15 relationships between a source node and one or more 
destination nodes, broadcasting object data divided 
into one or more segments by using one of the logical 
connection relationships, and discriminating the 
logical connection relationship and receiving the 

20 object data. 

As a further embodiment, the present invention 
discloses a data communication method comprising steps 
of successively transferring object data divided into 
one or more segments in an asynchrnous manner by using 

25 one of a plurality of logical connection relationships 
set between a plurality of nodes, and discriminating 
one of the plurality of logical connection 
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relationships and receiving the object data. 

As a still further embodiment, the present 
invention discloses a data communication method 
comprising steps of successively broadcasting object 
5 data divided into one or more segments by using one of 
a plurality of logical connection relationships set 
between a plurality of nodes, and discriminating one of 
the plurality of logical connection relationships and 
=n receiving the object data, 

ill 

jn 10 As a further embodiment, the present invention 

[r discloses a data communication method comprising steps 

of setting a logical connection relationship different 
^ from that set by other controller, between a source 

* y node and one or more destination nodes, and informing 

^ 15 the source node and one or more destination nodes of 

vS the logical connection relationship. 

As a still further embodiment, the present 
invention discloses a data communication method 
comprising steps of discriminating a plurality of 
20 logical connection relationships set between one or 
more destination nodes, and transferring object data 
divided into one or more segments in an asynchronous 
transferring by using one of the theoretical connection 
relations . 

25 As a further embodiment, the present invention 

discloses a data communication method comprising steps 
of discriminating a plurality of logical connection 
relationships set between source nodes, and receiving 
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object: data transferred from the source node in an 
asynchronous transferring and divided into one or more 
segments by using one of the logical connection 
relationships . 
5 As a still further embodiment, the present 

invention discloses a data communication apparatus 
comprising a unit for setting a logical connection 
relationship different from that set by other 

~ !! == 

vO controller, between a source node and one or more 

|R 10 destination nodes, and a unit for informing the source 

\ t g node and one or more destination nodes of the logical 

In connection relationship, 

m As a further embodiment, the present invention 

\2 discloses a data communication apparatus comprising a 

15 unit for discriminating a plurality of logical 
y connection relationships set between one or more 

destination nodes, and a unit for transferring object 
data divided into one or more segments in an 
asynchronous transferring by using one of the logical 
20 connection relationships* 

As the other embodiment, the present invention 
discloses a data communication apparatus comprising a 
unit for discriminating a plurality of logical 
connection relationships set between source nodes, and 
25 a unit for receiving object data transferred from the 
source node in an asynchrnous manner and divided into 
one or more segments by using one of the logical 
connection relationships . 
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The other objects and features of the present 
invention will be apparent from the following detailed 
explanation of preferred embodiment of the present 
invention. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a view for explaining a conventional 
system; 

*.B Fig. 2 is a block diagram showing an example of a 

i O 

! : f1 10 construction of a communication system acceding to an 

i,0 embodiment; 

§*- - 

l.f| Fig. 3 is a conceptional view or explaining a 

i ! 3 fundamental construction of a communication protocol 

a* according to a first embodiment of the present 

1 5 invention ; 

Figs. 4A and 4B are sequence charts for explaining 
a fundamental communication sequence of the 
communication protocol according to the first 
embodiment; 

20 Fig. 5 is a view showing a construction of an 

asynchronous broadcast packet according to the first 
embodiment; 

Figs. 6A and 6B are views for explaining address 
spaces of respective nodes; 
25 Fig. 7 is a view for explaining an example of a 

transfer model of object data in the first embodiment; 
Fig. 8 is a view for explaining a construction of 
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a 1394 interface according to the embodiment; 

Fig. 9 is a view for explaining a way for setting 
identical connection IDs by a plurality of controllers; 

Fig. 10 is a view for explaining a setting 
5 sequence and a releasing sequence of the connection; 

Fig. 11 is a view showing an example that one 
connection ID is set between one source node and N 
(number) destination nodes; 

O 

; r n Fig. 12 is a view for explaining a transfer 

ru 

ifl 10 sequence when receiving buffer sizes of the N (number) 

?,S destination nodes are equal; 

i y 

in Fig. 13 is a view for explaining a transfer 

pj sequence when receiving buffer sizes of the N (number) 

ru 

12 destination nodes are different; 

^ 15 Fig. 14 is a view for explaining another example 

• y of a transfer model of object data in the first 

embodiment ; 

Figs. 15A and 15B are sequence charts for 
explaining a transfer re-starting sequence between one 
20 source node and N (number) destination nodes; 

Fig. 16 is a conceptional view or explaining a 
fundamental construction of a communication protocol 
according to a second embodiment of the present 
invention; 

25 Figs. 17A and 17B are views showing a construction 

of a communication packet used in the second 
embodiment ; 
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Fig. 18 is a sequence chart showing an example of 
a communication protocol according to the second 
embodiment ; 

Fig. 19 is a sequence chart showing an example of 
5 another communication protocol according to the second 
embodiment; 

Fig. 20 is a view showing data format for command 
used in the second embodiment; 

Fig. 21 is a view showing data format for response 
10 corresponding to the command shown in Fig. 20; 

Fig. 22 is a view for explaining an example of a 
transfer model of object data in the second embodiment; 

Fig. 23 is a view showing a construction of a data 
field of an asynchronous streaming packet used in the 
15 second embodiment; 

Fig. 24 is a sequence chart for fully explaining a 
data transfer flow shown in Fig. 19; 

Fig. 25 is a view showing an example of format of 
an application header; 
20 Fig. 26 is a view showing a construction of a data 

field of an asynchronous streaming packet used in a 
third embodiment of the present invention; 

Fig. 27 is a sequence chart for fully explaining a 
data transfer flow according to the third embodiment; 
25 Fig. 28 is a view for explaining a construction of 

a response packet used in the third embodiment; 

Fig. 29 is a sequence chart for explaining a 
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communication sequence when an error occurs during the 
transferring of object data; and 

Fig. 30 is a sequence chart for explaining a 
communication sequence when bus reset occurs during the 
5 transferring of object data. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The preferred embodiment of the present invention 

will now be described in detail hereinafter with 
10 reference to the accompanying drawings. 

Fig. 2 is a view showing an example of a 

construction of a data communication system according 

to an embodiment of the present invention. As shown in 

Fig. 2, the data communication system according to this 
15 embodiment is constituted by a computer 10, a camera 

integrating digital video recorder 28, and a printer 

60. 

First of all, a construction of the computer 10 
will be described. The computer includes a calculation 

20 processing unit (MPU) 12 for controlling an operation 
of the computer 10, a 1394 interface 14 having a 
function for based upon the IEEE 1394-1995 Standard and 
a function regarding a communication protocol 
stipulated in this embodiment, an operation unit 16 

25 comprised of a keyboard and a mouth, a decoder 18 for 
decoding compressed and coded digital data (moving 
image data, still image data, video data and the like), 
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a display unit (display) 20 comprised of a display 
device such as a CRT display or a liquid crystal panel, 
a hard disc 22 for storing various digital data (moving 
image data, still image data, video data, graphic data, 
text data, program data and the like), an internal 
memory 24, and an internal bus 26 for interconnecting 
various processing units within the computer 10. 

Next, a construction of the camera integrating 
digital video recorder (referred to as "DVCR" 
hereinafter) 28 will be described. The DVCR includes 
an imaging unit ( opt ) 30 for converting an optical 
image of an object into an electric signal and for 
supplying the electric signal to an analogue/digital 
(A/D) converter 32, an image processing unit 34 for 
converting digitalized moving image and still image 
into digital image data having predetermined format, a 
compression/expansion processing unit 36 having a 
function for decoding the compressed and coded digital 
data (moving image data, still image data, video data 
and the like) and a function for coding the digital 
image data with high efficiency (for example, as is in 
an MPEG system and a DV system, for quant igating and 
coding the data with variable length after orthogonally 
converting the data into predetermined image units ) , a 
memory 38 for temporarily storing the digital image 
data coded with high efficiency, a memory 40 for 
temporarily storing the digital image data not coded 
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with high efficiency, a data selector 42, a 1394 
interface 44 having a function for based upon the IEEE 
1394-1995 Standard and a function regarding a 
communication protocol stipulated in this embodiment, 
memory control units 46, 48 for controlling writing and 
reading of the memories 38, 40, a control unit (system 
controller) 50 adapted to control an operation of the 
DVCR 28 and having a microcomputer, an operation unit 
52 comprised of a remote controller and an operation 
panel, an electronic view finder (EVF) 54, a D/A 
converter 56, and a recorder /reproducer unit 58 
comprised of a recording medium such as a magnetic 
tape, a magnetic disc, a photo-magnetic disc or the 
like and adapted to record and reproduce various data 
(moving image data, still image data, video data and 
the like ) . 

Next, a construction of the printer 60 will be 
described* The printer includes a 1394 interface 62 
having a function for based upon the IEEE 1394-1995 
standard and a function regarding a communication 
protocol stipulated in this embodiment, a data selector 
64, an operation unit 66 comprised of an operation 
button and a touch panel, a printer controller 68 for 
controlling an operation of the printer 60, a decoder 
70, an internal memory 72, an image processing unit 74 
for processing the still image data, text data, graphic 
data and the like received through the 1394 interface, 
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a driver 76, and a printer head 78. 

As shown in Fig. 2, various communication 
apparatuses (referred to as "nodes" hereinafter) such 
as the computer 10, DVCR 28 and printer 60 are 
5 connected to each other via the 1394 interfaces 14, 44, 
62 (hereinafter, a network constituted by the 1394 
interfaces is referred to as "1394 serial bus"). In 
the respective nodes, by defining predetermined 
communication protocols, sending and receiving of 

10 various object data (for example, moving image data, 

still image data, video data, graphic data, text data, 
program data and the like) and remote control based on 
command data can be performed. In the illustrated 
embodiment, a communication protocol using an 

15 asynchronous transfer system is defined. 

Next, operations of respective nodes constituting 
the communication system according to the illustrated 
embodiment will be explained with reference to Fig. 2. 
First of all, functions and operations of various 

20 processing units constituting the computer 10 will be 
described. 

In the illustrated embodiment, for example, the 
computer 10 acts as a computer for controlling 
transmission and reception of image data between the 
25 DVCR 28 and the printer 60 or a computer for remotely 
controlling the DVCR 28 and the printer 60. 

The MPU 12 serves to execute softward recorded in 
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the hard disc 22 and to shift various data to the 
internal memory 24. Further, the MPU 12 also serves to 
adjust the various processing units connected to the 
MPU via the internal bus 26. 
5 The 1394 interface 14 serves to receive the image 

data transferred onto the 1394 serial bus and to send 
the image data stored in the hard disc 22 or the 
internal memory 24 to the 1394 serial bus. Further, 
the 1394 interface 14 serves to transmit the command 

10 data for remotely controlling other nodes on the 1394 
serial bus. In addition, the 1394 interface 14 has a 
function for transferring a signal transferred through 
the 1394 serial bus to other node. 

The user or operator can select desired software 

15 via the operation unit 16 and cause the MPU 12 to 
execute the soft ware stored in the hard disc 22. 
Information regarding the software is displayed to the 
user through the display unit 20. The decoder 18 
serves to decode the image data received from the 1394 

20 serial bus, on the basis of the software. The decoded 
image data is represented to the user through the 
display unit 20. 

Next, functions and operations of various 
processing units constituting the DVCR 28 will be 

25 described. 

In the illustrated embodiment, for example, the 
DVCR 28 acts as an image transmitting device ( source 
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node) for transferring the image data in an 
asynchronous transferring on the basis of the 
communication protocol according to the illustrated 
embodiment . 

The imaging unit 30 serves to convert the optical 
image of the object into the electric signal comprised 
of a luminance signal (Y) and a color difference signal 
(C) and to supply the electric signal to the A/D 
converter 32. The A/D converter 32 serves to 
digitalize the electric signal. 

The image processing unit 34 serves to effect 
predetermined image processing with respect to the 
digitalized luminance signal and color difference 
signal and to multiply the signals. The 
compression/expansion processing unit 36 serves to 
compress data amounts of the digitalized luminance 
signal and color difference signal. The 
compression/expansion processing unit 36 may process 
the luminance signal and the color difference signal in 
parallel by using independent compression processing 
circuits . 

Further, in the compression/expansion processing 
unit 36, in order to increase resistance to 
transmission path error, the compressed image data is 
subjected to shuffling process. As a result, 
continuous code error (i.e., burst error) can be 
converted into scattered error (i.e., random error) 
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which can easily be corrected or interpolated. When it 
is desired to make offset of information amount due to 
roughness/density of in the image uniform, before the 
compressing process, this process is effected. It is 
5 advantageous particularly when the coding with variable 
length such as run length is used. 

In the compression/expansion processing unit 36, 
data discriminating information (ID) for restoring the 

C3 

<:B shuffling is added to the compressed image data. 

ru 

ifl 10 Further, the compression/expansion processing unit 36 

U3 adds an error correction code ( ECC ) to the compressed 

Iff image data in order to reduce error in 

p recording/reproducing . 

I'll 

il The image data compressed in the 

15 compression/expansion processing unit 36 is supplied to 
the memory 30 and the recorder/reproducer unit 58. The 
recorder /reproducer unit 58 serves to record the added 
compressed image data such as ID or ECC on a recording 
medium such as a magnetic tape. The compressed image 

20 data is recorded on an independent recording area 
different from the video data. 

On the other hand, the image data supplied from 
the image processing unit 34 to the D/A converter 56 is 
D/A-converted. The EVF 54 serves to display an 

25 analogue image signal supplied from the D/A converter 
56. Further, the image data processed in the image 
processing unit 34 is also supplied to the memory 40. 
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Non-compressed image data is stored in the memory 40. 

The data selector 42 selects the memory 38 or the 
memory 40 on the basis of the user's command and 
supplies the compressed image data or the non- 
5 compressed - image data to the 1394 interface 44. 

Further, the data selector 42 supplies the image data 
supplied from the 1394 interface 44 to the memory 38 or 
^ the memory 40 . 

The 1394 interface 44 serves to transfer the 
In 10 compressed image data or the non-compressed image data 
tS in asynchronous transferring on the basis of a 

BIjj ; 

i %S 

\f] communication protocol according to the illustrated 

embodiment which will be described later. Further, the 
Jl 1394 interface 44 serves to receive control command for 

: 2 15 controlling the DVCR 28 through the 1394 serial bus. 

The received control command is supplied to the control 
unit 50 through the data selector 42. The 1394 
interface 44 sends back response to the control 
command . 

20 Next, functions and operations of various 

processing units constituting the printer 60 will be 
described . 

In the illustrated embodiment, for example, the 
printer 60 acts as an image receiving device 
25 (destination node) for receiving the image data 

transferred in the asynchronous transferring and for 
printing the image data, on the basis of the 
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communication protocol according to the illustrated 
embodiment. 

The 1394 interface 62 serves to receive the image 
data transferred in the asynchronous transferring and 
5 the control command through the 1394 serial bus. The 
1394 interface 62 also serves to transmit response to 
the control command. 

The received image data is supplied to the decoder 
70 through the data selector 64. The decoder 70 serves 
10 to decode the image data and output a result to the 

image processing unit 74. The image processing unit 74 
causes the memory 72 to temporarily store the decoded 
image data. 

Further, the image processing unit 74 serves to 
15 convert the image data temporarily stored in the memory 
72 into printing data and supply the print data to the 
printer head 78. The printer head 78 executes the 
printing under the control of the printer controller 
68. 

20 On the other hand, the received control command is 

inputted to the printer controller 68 through the data 
selector 64. The printer controller 68 performs 
various controls regarding the printing on the basis of 
the control data. For example, the printer controller 

25 controls sheet feed through the driver 67 and 
positioning of the printer head 78. 

Next, constructions of the 1394 interfaces 14, 44, 
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62 according to the illustrated embodiment will be 
fully described with reference to Fig. 8. 

The 1394 interface is functionally constituted by 
a plurality of layers. In Fig. 8, the 1394 interface 
5 is connected to the 1394 interface of other node via a 
communication cable 801 based upon the IEEE 1394-1995 
Standard. Further, the 1394 interface has one or more 
communication ports 802, and each communication port is 
connected to a physical layer 803 included in a 

10 hardware portion. 

In Fig. 8, the hardware portion includes the 
physical layer 803 and a link layer 804. The physical 
layer 803 acts as a physical and electrical interface 
for other node and serves to effect detection of bus 

15 reset and processing therefor, coding/decoding of input 
and output signals and adjustment of bus usage right. 
The link layer 804 serves to effect formation of the 
communication packets, transmission and reception of 
various communication packets and control of a cycle 

20 timer. Further, the link layer 804 provides a function 
for performing formation and transmission/reception of 
an asynchronous broadcast packet which will be 
described later. 

In Fig. 8, a firmware portion includes a 

25 transaction layer 805 and a serial bus management 806. 
The transaction layer 805 controls an asynchronous 
transfer system and provides various transactions 
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(read, write, lock). Further, the transaction layer 
805 provides an asynchronous broadcast transaction 
function which will be described later. The serial bus 
management 806 provides functions for effecting control 
5 of its node, management of a connection condition of 

its node, management of ID information of its node, and 
resources management of the serial bus network. 

The hardware portion and the firmware portion 
shown in Fig. 8 substantially constitute the 1394 
10 interface, and fundamental constructions thereof are 
stipulated in the IEEE 1394-1995 Standard. 

An application layer 807 included in the software 
portion differs from each other depending upon 
application soft used and controls how to transfer what 
15 kind of object data. 

The communication protocol according to the 
illustrated embodiment which will be described later 
serves to expand the functions of the hardware portion 
and the firmware portion which constitute the 1394 
20 interface and provides a new transfer sequence to the 
software portion. 
( First Embodiment ) 

Next, a fundamental construction of the 
communication protocol stipulated in the illustrated 
25 embodiment will be described with reference to Fig. 3. 

In Fig. 3, the reference numeral 300 denotes a 
controller; 302 denotes a source node; 304 denotes n 
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(n > 1) (number) destination nodes; 306 denotes a 
subunit of the source node; and 308 denotes object data 
such as still image data, graphic data, text data, file 
data, program data or the like. 
5 The reference numeral 310 denotes a first memory 

space within the destination node 304 and is designated 
by predetermined destination offset (#0); and 312 
denotes first connection showing a logical connection 
^0 relationship (i.e., connection) between the source node 

ru 

[n 10 302 and the destination node 304. The destination 
offset means address for commonly designating the 

I'd 

if; memory spaces of the n (number) destination nodes 304. 

ji^ The reference numeral 314 denotes n-th memory 

space within the destination node 304 and is designated 
15 by predetermined destination offset (#n); and 316 

denotes n-th connection showing a logical connection 
relationship (i.e., connection) between the source node 
302 and the destination node 304. 

In this embodiment, each node controls or governs 
20 the first memory space 310 to n-th memory space 314 on 
the basis of 64-bit address spaces based upon IEEE1212 
CSR ( Control and Status Register Architecture ) Standard 
(or ISO/IEC 13213:1944 Standard). IEEE1212 CSR 
Standard is Standard for stipulating control, 
25 management and address assignment of serial bus. 

Figs. 6A and 6B are views for explaining the 
address space of each node, where Fig. 6A shows a 
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-theoretical memory space represented by 64-bit address, 
and Fig. 6B shows a part of the memory space shown in 
Fig. 6A (for example, an address space where larger 16 
bits become FFFF 16 ) . The first memory space 310 to n-th 
5 memory space 314 shown in Fig. 3 use a part of the 
memory space shown in Fig. 6B. Each of the memory 
spaces 310-314 is designated by destination offset 
indicating lower 48 bits of the address. 

In Fig. 6B, for example, 000000000000 16 to 
10 0000000003FF 16 are reserved areas, and, areas where the 
object data 308 is actually written are areas where the 
lower 48 bits of the address become FFFFF0000400 16 and 
so on. 

In Fig. 3, the source node 302 means a node having 
15 a function for transferring the object data 308 in 

accordance with the communication protocol which will 
be described later, and the destination node 304 means 
a node having a function for receiving the object data 
308 transferred from the source node 302. Further, the 
20 controller 300 means a node having a function for 
setting a logical connection relationship (i.e., 
connection) between the source node 302 and one or more 
destination nodes 304 and for controlling the relation, 
in accordance with the communication protocol which 
25 will be described later. 

The controller 300, source node 302 and 
destination node 304 may be operated in independent 
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nodes. Alternatively, the controller 300 and the 
source node 302 may be operated in a single same node. 
Alternatively, the controller 300 and the destination 
node 304 may be operated in a single same node. In 
5 this case, the transaction between the controller 300 

and the source node 302 or the destination node 304 can 
be omitted, thereby simplifying the communication 
^ sequence . 

*S In the illustrated embodiment, a case where the 

fU 

I.P1 10 controller 300, source node 302 and destination node 

5 : : 

*,B 304 are operated in independent nodes will be 

J,fj explained. For example, the computer 10 having the 

p 1394 interface 14 acts as the computer 300. Further, 

\1 the DVCR 28 having the 1394 interface 44 acts as the 

/5 15 source node 302 and the printer 60 having the 1394 

Vb? interface 62 acts as the destination node 304. 

In the illustrated embodiment, as shown in Fig. 3, 
one or more connections can be set between the source 
node 302 and one or more destination nodes 304. When 
20 it is required that certain object data be transferred, 
one or plural controllers 300 set such connections on 
the basis of the communication protocol which will be 
described later. 

In the illustrated embodiment, the destination 
25 offset capable of being used in one connection can be 
set by one or by plural. A value of the destination 
offset may be a predetermined value or a value variably 
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set by the controller 300 or the source node 302. 
Incidentally, a relation between the connection and the 
destination offset is set on the basis of the 
communication protocol which will be described later. 
5 When a plurality of destination offsets are set 

regarding to one connection, data communication having 
plural patterns can be achieved by one connection. For 
example, by assigning different destination offsets to 

5,3 respective patterns of the data communication, data 

i'U 

l.fl 10 communications having 1:1, 1:N and N:N can be achieved 

=p simultaneously by one connection. 

jn Incidentally, in the illustrated embodiment, the 

computer 10 as the controller 300 may be operated as 
J 5 : the destination node 304. In this case, the 

"~ 15 connections are set between one source node 302 and two 

■0 destination nodes 304 to transfer the object data 308. 

Further, in the illustrated embodiment, while an 
example that the computer 10 is operated as the 
controller 300 was explained, it is not necessary that 
20 the computer 10 acts as the controller 300. The DVCR 
20 or the printer 60 may be operated as the controller 
300. 

Next, a fundamental communication sequence of the 
communication protocol stipulated in the illustrated 
25 embodiment will be explained. 

Fig. 4A is a sequence chart for explaining a 
sequence until one object data is transferred by using 



the connection set: by a certain controller 300. Fig. 
4B is a sequence chart for explaining a transfer 
sequence when bus reset or a transfer error occurs 
during the transferring of one object data. 

In the communication protocol according to the 
illustrated embodiment, after the above-mentioned 
connection is set by the certain controller 300, one 
object data is transferred by one or more asynchronous 
broadcast transactions. A detailed communication 
sequence of the asynchronous broadcast transaction will 
be explained with reference to Figs. 4A and 4B. 
Further, a packet used in the asynchronous broadcast 
transaction (referred to as "asynchronous broadcast 
packet" hereinafter) will be explained with reference 
to Fig. 5. 

Incidentally, the above-mentioned asynchronous 
broadcast transaction and asynchronous broadcast packet 
are new communication sequence and packet format 
stipulated in the communication protocol according to 
the illustrated embodiment. 

Now, a fundamental transfer sequence based on the 
communication protocol according to the illustrated 
embodiment will be described with reference to Fig. 4A. 

The controller 300 sets connection ID for 
discriminating a logical connection relationship 
(connection) between the source node 302 and one or 
more destination nodes 304. Then, the controller 300 



- 32 - 



informs respective nodes of "the connection ID and world 
wide unique ID of the controller itself and sets one 
connection (401, 402 in Fig. 4A). 

After information of the connection ID, the 
5 controller 300 commands the source node 302 to start 
the transferring of the object data 308 (403 in Fig. 
4A) . 

After the command for starting the transferring is 

i;B received, the source node 302 executes negotiation with 

n I 

a "SET 

Ml 10 one or more destination nodes 304, thereby effecting 

H I 

initial setting of the asynchronous broadcast 

II! 

t : fl transaction (404, 405 in Fig. 4A). 

f;3 After the initial setting is finished, the source 

! y 

t± node 302 executes the asynchronous broadcast 

15 transaction, thereby successively broadcasting the 
^ object data 308 including one or more segment data 

(406-409 in Fig. 4A). 

Now, a transfer mode of the object data in the 
illustrated embodiment will be described with reference 
20 to Fig. 7. In Fig. 7, for example, the object data is 
a still image data in which data size is 128 Kbytes. 

The source node 302 divides the object data 308, 
for example, into 500 segment data (one segment data 
has 256 bytes) in accordance with the receiving ability 
25 of each destination node 304 discriminated in the 

initial setting. The data size of one segment data is 
variably set by the source node 302 on the basis of a 
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size of an internal buffer of each destination node 
304. Fig, 7 shows a case where the internal buffer 
having a size same as the data size of the object data 
308 is reserved. 
5 Further, the source node 302 transfers one or more 

segment data by using at least one asynchronous 
broadcast transaction. In Fig. 7, one segment data is 
transferred by using one asynchronous broadcast 
*,3 transaction. 

In 10 After all of the segment data are transferred, the 

uj source node 302 finishes the data communication with 

jjn respect to one or more destination nodes 304 (410, 411 

5=3 in Fig. 4A ) . 

Next, the operation of the controller 300 will be 
15 fully explained with reference to Fig. 4A. 
• y The controller 300 transfers the packet for 

setting the connection (referred to as "connection 
setting packet" hereinafter) in the asynchronous 
transferring to the source node 302 and one or more 
20 destination nodes 304 selected by the user (401, 402 in 
Fig. 4A). The connection ID and the world wide unique 
ID are stored in a pay load of this packet. 

Then, the controller 300 transfers a transaction 
command packet to the source node 302 in the 
25 asynchronous transferring (403 in Fig. 4A). 

The source node 302 which received the transaction 
command packet effects the initial setting by using the 
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connection ID and the world wide unique ID informed 
from the controller 300 and executes the asynchronous 
broadcast transaction (404-409 in Fig. 4A). By this 
asynchronous broadcast transaction, the source node 302 
can transfer the object data 308 comprised of one or 
more segment data successively. 

Incidentally, in the communication protocol 
according to the illustrated embodiment, the controller 
300 provides a function for controlling 
connection/disconnection of the connection. 
Accordingly, the transferring of the object data 308 
after the setting of the connection is executed by the 
negotiation between the source node 302 and the 
destination node 304. 

After a series of asynchronous broadcast 
transactions are finished, the source node 302 
broadcasts an asynchronous broadcast packet indicating 
segment end (referred to as "segment end packet" 
hereinafter) (410 in Fig. 4A). 

After receiving the segment end packet from the 
source node 302, the controller 300 releases the 
connection, thereby finishing the data transferring 
(411 in Fig. 4A) . 

Since the segment end packet is transferred, the 
contents of the packet can also be detected in the 
destination node 304. Accordingly, in place of the 
controller 300, the destination node 304 itself may 
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release the connection to the source node 302. 

Next, the operation of the source node 302 will be 
fully explained with reference to Fig. 4A. 

After receiving the connection setting packet and 
the transaction command packet from the controller 300, 
the source node 302 sends to each destination node 304 
an asynchronous broadcast packet requesting data 
transferring (referred to as "send request packet" 
hereinafter) (404 in Fig. 4A). 

The send request packet is a request packet for 
obtaining required initial information before execution 
of the asynchronous broadcast transaction of the object 
data 308. The connection ID and the world wide unique 
ID of the controller 300 designated by the controller 
300 are written in this packet. 

The destination node 304 broadcasts an 
asynchronous broadcast packet indicating the fact that 
packet corresponds to the send request packet ( referred 
to as "ack response packet" hereinafter) (405 in Fig. 
4A). Connection ID and world wide unique ID, same as 
those in the send request packet are stored in the ack 
response packet. Accordingly, the source node 302 can 
discriminate the connection through which the ack 
response packet is transferred, by recognizing the 
connection ID and the world wide unique ID of the 
received packet . 

A size of the internal buffer capable of being 
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reserved in each destination node 304 and offset 
address designating a predetermined memory space are 
stored in the ack response packet. After receiving the 
ack response packet, the source node 302 sets 
5 destination offset for commonly designating the memory 
spaces of the destination nodes 304 and starts the 
asynchronous broadcast transaction. The destination 
offset is set by using offset address included in the 

^0 ack response packet of each destination nodes 304. 

i 

Ih 10 Incidentally, in the illustrated embodiment, while 

sTU 

=,0 an example that the destination offset used in the 

[ff asynchronous broadcast transaction is set by using the 

p offset address included in the ack response packet was 

I y 

s ib l explained, the present invention is not limited to such 

^ 15 an example. For example, the controller 300 may have a 

w function for controlling the destination offset used in 

each connection to set both the connection ID and the 
destination offset. In this case, the destination 
offset corresponding to each connection is informed 
20 from the controller 300 to the source node 302. 

Then, the source node 302 writes the first 
asynchronous broadcast packet in the memory space 
indicating the above-mentioned destination offset (406 
in Fig. 4A). The connection ID, the world wide unique 
25 ID and a sequence number of the segment data are stored 
in this packet. 

After receiving the first asynchronous broadcast 
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packet:, the source node 302 is waiting for the response 
packet from the destination node 304. From the 
destination node 304, the response packet storing the 
connection ID, the world wide unique ID and the 
5 sequence number is sent in the form of the asynchronous 
broadcast packet. After receiving this response 
packet, the source node 302 effect increment of the 
sequence number and transfers the asynchronous 
broadcast packet including next segment data ( 407 in 

10 Fig. 4A). 

By repeating such sequences, the source node 302 
effects the asynchronous broadcast transactions 
successively (408, 409 in Fig. 4A). A maximum time 
period for waiting for the response from the 

15 destination node 304 is previously determined, and, if 
there is no response even when such a time period is 
elapsed, the same data is re-sent by using the same 
sequence number . 

When the response packet requesting the re-sending 

20 is transferred from the destination node 304, the 

source node 302 can broadcast data of the designated 
sequence number again. 

After the asynchronous broadcast transactions of 
all of the object data 308 are finished, the source 

25 node 302 broadcasts the segment end packet, thereby 

finishing the data transferring (410, 411 in Fig. 4A). 
As mentioned above, the source node 302 divides 
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the object data 308 into one or more segment data on 
demand (segmentation). The above-mentioned response 
packet is generated when the asynchronous broadcast 
transaction of each segment data is effected. The 
5 transferring of one segment data is effected by the 
single asynchronous broadcast transaction. The 
destination node 304 has a buffer having a capacity 
indicated by the above-mentioned buffer size. 

!;H Incidentally , in the above-mentioned example, 

I y 

10 while the response packet was sent out in accordance 

y with the asynchronous broadcast transaction of one 

i?l segment data without fail, the present invention is not 

O limited to such an example. After the data buffer of 

ru 

the destination node 304 is filled with a plurality of 
15 continuous segment data, the destination node 304 may 
send the response packet. 

Next, the operation of the destination node 304 
will be fully explained with reference to Fig. 4A. 

After receiving the connection setting packet from 
20 the controller 300, the destination node 304 is waiting 
for the send request packet from the source node 302 
(404 in Fig. 4A). 

The destination node 304 which received the send 
request packet recognizes the connection ID and the 
25 world wide unique ID written in this packet and judges 
whether or not this packet is sent from the source node 
302. 
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After receiving the send request packet from the 
source node 302, each destination node 304 broadcasts 
the ack response packet in which the connection ID, the 
world wide unique ID, the size of the internal buffer 
5 capable of being reserved and the offset address 

designating the predetermined memory space (405 in Fig. 
4A) . 

After the asynchronous broadcast packet 

ST--S 

'.u transferred from the source node 302 is written in the 

IH 10 memory space, the destination node 304 recognizes the 

i : y connection ID and the world wide unique ID of this 

ffl packet. When these connection ID and world wide unique 

p ID coincide with values set by the controller 300, the 

\2 response packet (including the connection ID, the world 

^ 15 wide unique ID and the sequence number included in the 

v ~ received packet) is broadcasted (406-409 in Fig. 4A). 

In this case, the segment data included in the received 
packet is stored in the internal buffer. If the 
connection ID and the world wide unique ID differ from 
20 the connection ID and the world wide unique ID set for 
the destination node, the destination node 304 discards 
the received packet . 

If the sequence number of the received packet is 
erroneous, the destination node 304 can send the 
25 response packet requesting the re-sending. In this 

case, the destination node 304 informs the source node 
302 of the sequence number requesting the re- sending. 
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After all of the asynchronous broadcast 
transactions are finished, the segment end packet is 
broadcasted from the source node 302. When receiving 
this packet, the destination node 304 finishes the data 
5 transferring process (410 in Fig. 4A). 

After receiving the segment end packet, the 
destination node 304 broadcasts a response packet 
indicating the fact that the segment end packet is 
correctly received (411 in Fig. 4A). 

10 As mentioned above, the communication system 

according to the illustrated embodiment can eliminate 
the inconveniences of the conventional communication 
systems. Further, in the transferring of data which 
does not require the real time ability, the data can be 

15 transferred simply at a high speed. 

Further, in the illustrated embodiment, after the 
connection is set by the controller 300, the transfer 
process of the object data is effected between the 
source node 302 and each destination node 304 without 

20 being controlled by the controller 300. As a result, a 
load on the controller can be reduced and a simple 
communication protocol having no complicated 
communication sequence can be provided. 

Further, in the illustrated embodiment, 

25 destination node 304 is designed to return the response 
to each asynchronous broadcast transaction. As a 
result, a communication protocol in which the data not 
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requiring the real time ability can positively be 
transferred can be provided. 

In order to realize more positive data 
transferring, if the data transferring is interrupted 
5 due to occurrence of bus reset or any transfer error, 

it is required that the data transferring is re-started 
quickly without loosing the data. Now, the re-starting 
sequence stipulated by the communication protocol 

o 

'=0 according to the illustrated embodiment will be 

!,n 10 described with reference to Fig. 4B. 

ru 

For example, after receiving the asynchronous 
jiff broadcast packet having the sequence number i, if the 

pj bus reset occurs, each node interrupts the transferring 

jl process and executes initialization of the bus, 

: ? 15 recognition of the connecting construction and setting 

of the node ID in accordance with the sequence 
stipulated by the IEEE 1394-1995 Standard (420, 421 in 
Fig. 4B). 

After the re-construction of the bus is completed, 
20 each destination node 304 broadcasts a resend request 
packet in which the connection ID, the world wide 
unique ID and the sequence number i are stored ( 422 in 
Fig. 4B). 

When the re-starting of the asynchronous broadcast 
25 transaction is permitted, the source node 302 

recognizes the connection ID and the world wide unique 
ID of the received resend request packet and broadcasts 
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the ack response packet: in which the connection ID and 
world wide unique ID are stored (423 in Fig. 4B ) . 

Thereafter, the source node 302 successively 
broadcasts the segment data subsequent to the sequence 
number requested by the received resend request packet, 
i.e., segment data having a sequence number (i + 1) and 
so on (424 in Fig. 4B ) . 

By the above-mentioned sequence, the controller 
300, source node 302 and destination node 304 can 
restart subsequent data transferring easily and 
positively even if the data transferring is 
interrupted, without taking the node IDs thereof. 

Further, as mentioned above, in the illustrated 
embodiment, even when the data transferring is 
interrupted, the control sequence of the controller 300 
can be simplified. 

Next, the construction of the asynchronous 
broadcast packet stipulated in the illustrated 
embodiment will be explained with reference to Fig. 5. 
For example, the asynchronous broadcast packet is a 
data packet having unit of 1 quadlet ( 4 bytes = 32 
bits ) . 

First of all, a construction of a packet header 
521 will be described. 

In Fig. 5, a field 501 (16 bits) indicates 
destination_ID and indicates node ID of the receiver 
(i.e., destination node 304). In the communication 
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protocol according to the illustrated embodiment, in 
order to realize the asynchronous broadcast transaction 
of the object data 308, a value of this field is used 
as broadcast ID (i.e., "FFFF 16 " ). 
5 A field 502 (6 bits) indicates a transaction label 

(tl) field and is a tag inherent to each transaction. 

A field 503 (2 bits) indicates a retry ( rt ) code 
and designates whether the packet tries retry or not. 
v3 A field 504 (4 bits) indicates a transaction code 

In 10 (tcode). The "tcode" designates format of the packet 

ru 

VB and type of the transaction to be executed. In the 

§ 

in illustrated embodiment, a value of this field is 

13 regarded as M 0001 2 ", for example, a process for writing 

i.I a data block 522 of this packet in the memory space 

.g 15 indicated by a destination_of f set field 507 (i.e., 

" write transaction) is requested. 

A field 505 (4 bits) indicates priority (pri) and 
designates a preferential order. In the illustrated 
embodiment, a value of this field is regarded as 
20 "0000 2 " . 

A field 506 (16 bits) indicates source_ID and 
indicates node ID of the sender (i.e., source node 
302) . 

A field 507 (48 bits) indicates destination_of f set 
25 and commonly designates lower 48 bits of the address 
space of each destination node 304. The destination_ 
offset may be set to the same value in all of 
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connections or may be set: to a different value for each 
connection. However, when the destination_of f set is 
set to the different value, since the asynchronous 
broadcast packets from a plurality of connections can 
5 be processed in parallel, it is mode efficiently. 

A field 508 (16 bits) indicates data_length and 
indicates a length of the data field with a bite unit. 

A field 509 (16 bits) indicates extended_tcode . 
In the illustrated embodiment, a value of this field is 
10 regarded as "0000 2 " . 

A field 510 (32 bits) indicates header_CRC and 
error detecting codes for the fields 501 to 509 are 
stored in this field. 

Next, a construction of the data block 522 will be 
15 described. In the illustrated embodiment, the data 

block 522 is constituted by header information 523 and 
data field 524. 

Connection IDs for discriminating logical 
connection relationships (i.e., connections) between 
20 the nodes are stored in the header information 523 . 
Incidentally, the construction of the header 
information 523 differs from each other in dependence 
upon the purpose of use. 

The data field 524 is a field having variable 
25 length, and the above-mentioned segment data is stored 
in this field. If the segment data stored in the data 
field 524 is not multiple of the quadlet, a part short 
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-to the quadlet is filled with "0". 

A field 511 (2 quadlets, 64 bits) is the world 
wide unique ID of the controller 300. The 1394 
interface according to the illustrated embodiment 
discriminates the controller 300 by which the 
connection between the source node 302 and the 
destination node 304 is set, by using this world wide 
unique ID. The world wide unique ID is ID inherent to 
each node and based upon the IEEE 1394-1995 Standard. 

Incidentally, in the illustrated embodiment, while 
an example that the world wide unique ID is used as the 
information for discriminating the controller setting 
the connection was explained, the present invention is 
not limited such an example. So long as each node can 
be discriminated inherently without being changed by 
the bus reset, other information may be used. 

A field 512 (16 bits) indicates connection_ID and 
stores the connection ID according to the illustrated 
embodiment. The 1394 interface according to the 
illustrated embodiment discriminates the connection set 
between the source node 302 and one or more destination 
nodes 304, on the basis of the connection ID stored in 
this field. In the illustrated embodiment, one 
controller can establish 2 16 x (node number) 
connections. With this arrangement, until the total 
amount of communication bands or areas used by the 
connections reaches the capacity of the transfer path, 
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a plurality of connections can be set. 

Further, the 1394 interface according to the 
illustrated embodiment can discriminate absolute 
connections set between a certain source node 302 and 
5 one or more destination nodes 304, by using the above- 
mentioned world wide unique ID and connection ID. 
Accordingly, the plurality of controllers 300 can set 
the same connection ID regarding two different logical 
connection relationships. Namely, each controller can 

10 set and control the connection ID thereof regardless of 
the connection IDs set by other controllers. 

A field 513 (8 bits) indicates protocol_type, and, 
when the communication protocol according to the 
illustrated embodiment is indicated, a value of this 

15 field becomes lf 01 16 " , for example. 

A field 514 (8 bits) indicates control_f lags, and 
predetermined control data for controlling the 
communication sequence of the communication protocol 
according to the illustrated embodiment and the like is 

20 set in this field. In the illustrated embodiment, the 
highest bit of this field is used as a resend request 
flag, for example. Accordingly, when the highest bit 
of this field becomes "1", the fact that the resend 
request based on the communication protocol according 

25 to the illustrated embodiment is generated is 
indicated . 

A field 515 (16 bits) indicates sequence_number 
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and sets continuous values (i.e., sequence number) for 
the packet transferred on the basis of the particular 
connection ID (connection ID designated in the field 
512). By this sequence number, the destination node 
304 can monitor the continuity of the segment data 
successively subjected to the asynchronous broadcast 
transaction. If discord occurs, the destination node 
304 can request the re-sending on the basis of this 
sequence number . 

A field 516 (16 bits) indicates re-confirmation 
number. In the illustrated embodiment, this field has 
a meaning only when the value of the resend request 
flag is "1". For example, when the value of the resend 
request flag is "1", the sequence number of the packet 
requesting the re-sending is set in this field. 

A field 517 (16 bits) indicates buffer_size. A 
buffer size of the destination node 304 is set in this 
field. 

A field 518 (48 bits) indicates of f set_address . 
Lower 48 bits of the address space of the destination 
node 304 is stored in this field. As a result, one of 
the first memory space 310 to n-th memory space 314 
shown in Fig. 3 is designated. 

A field 519 (32 bits) indicates data_CRC, and, 
similar to the header_CRC, error detecting codes for 
the header information 523 (fields 511-518) and the 
data field 524 are stored in this field. 
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Next, a way in which the identical connection IDs 
are set on a network by two controllers will be fully 
described with reference to Fig. 9. A controller A300 
shown in Fig. 9 has node unique discrimination ID 901 
5 which is not changed even if the bus reset and the like 
occurs. Here, the discrimination ID 901 is world wide 
unique ID based on the IEEE 1394-1995 Standard and a 
value thereof is set to " 1", for example. 
^ Similar to the controller A300, a controller B300 ' 

H 10 shown in Fig. 9 has node unique discrimination ID 902 

0 which is not changed even if the bus reset and the like 

0 occurs. Here, the discrimination ID 902 is world wide 

;3 unique ID based on the IEEE 1394-1995 Standard and a 

si 

a value thereof is set to "4", for example. By the world 

15 wide unique IDs, the respective controllers A, B can 
set the identical connections between the same or 
different source node 302 and the destination node 304. 
In Fig. 9, the connection IDs are set to "0", for 
example. 

20 When the identical connection IDs are set, the 

controllers A, B do not require negotiation for 
preventing overlapping of connection IDs between the 
controllers A and B. 

When the connections is set, the controllers A, B 
25 inform the source node 302 and the destination node 304 
of the connection ID and the node unique discrimination 
ID 901 (902) of the controllers A (B). As a result, 
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the source node 302 and -the destination node 304 can 
discriminate the connection and the controller by which 
the connection is set. 

Next, a sequence for setting the connection and a 
5 sequence for releasing the connection effected by the 
controller 300 will be fully described and 
supplementary explanation of Figs. 4A and 4B will be 
made. 

(1) First of all, the controller 300 queries the 
10 N (N > 1) destination node 304 about the maximum pay 

load size (i.e., max_rec size) which is allowed in one 
asynchronous broadcast transaction and informs the 
destination node of the unique connection ID set by the 
controller 300. The destination node 304 indicates the 
15 max_rec size to the command from the controller 300 and 
returns the response showing the fact that the 
connection ID is set (1001 in Fig. 10). 

( 2 ) Then, the controller 300 informs the source 
node 302 of the connection ID for discriminating the 

20 connection set by the controller 300, the world wide 

unique ID of the controller 300, the total number N of 
the destination nodes 304 theoretically connected by 
the connection, and the above-mentioned max_rec size 
(this value indicates the size of the pay load of the 

25 asynchronous broadcast packet send by the source node 
302) (1002 in Fig. 10). The source node 302 returns 
the response indicating that they are set to the 
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command from the controller 300. 

(3) The controller 300 selects one object data 
308 which is desired to be sent among the object data 
of the source node 302 (1003 in Fig. 10). The source 
5 node 302 returns the response indicating that the 

desired object data 308 is selected to the controller 
300. The selected object data 308 may be a still image 
or a moving image. Alternatively, the object data may 
h.n be text data or binary data. 

lf\ 10 (4) After the controller 300 recognizes the fact 

,p that the source node 302 can send the object data 308 

m on the basis of the response from the source node 302, 

the controller sends the command (i.e., transaction) 
:^ for commanding the start of the sending of the object 

15 data 308 to the source node 302 (1004 in Fig. 10). 
^ ( 5 ) When receiving the transaction command from 

the controller 300, the source node 302 starts the 
sending of the selected object data 308 (1005 in a Fig. 
10). As mentioned above, the object data 308 is 
20 transferred to the destination node 304 by one or more 
asynchronous broadcast transactions . 

(6) After the sending of the object data 308 is 
finished, the controller 300 releases the object data 
308 of the source. 
25 (7) At this point, the controller 300 queries the 

source node 302 about the fact that the sending of 
further object data is required or not. If yes, the 
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above-mentioned sequences (3) to (6) are repeated. 

(8) After all of the object data are sent, the 
controller 300 releases the previously set unique 
connection (1007, 1008 in Fig. 10). 
5 Fig. 11 shows a construction in which one 

connection ID is set between one source node 302 and N 
(number) destination nodes 304 on the network by one 
controller 300. In this case, the unique connection ID 
for discriminating the connections between the nodes is 

10 regarded as "FFFF" (16 scale). Incidentally, this 
value may be other value. 

In this case, the sequence (1) shown in Fig. 10 is 
effected for respective destination nodes 304 and, 
thus, is repeated by N times. 

15 Next, a communication sequence in which the 

respective destination nodes 304 have the same size 
receiving buffers and the sizes of the object data 308 
are equal to the receiving buffers will be explained 
with reference to Fig. 12. In order to facilitate the 

20 explanation, it is assumed that the number N of the 
destination nodes 304 is three (N = 3). In Fig. 12, 
the source node 302 recognizes the fact that there are 
three destination nodes connected by the same 
connection ID, on the basis of the sequences shown in 

25 Fig. 10 (1201 in Fig. 12). 

(1) When the transaction command from the 
controller 300 is sent to the source node 302, the 
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source node 302 broadcasts the connection request 
packet in accordance with the sequences shown in Fig. 
4A (1202 in Fig. 12) . 

( 2 ) At the point that preparation of receiving is 
5 completed, the three destination nodes 304 return the 

ack response packets including the sizes of the 
receiving buffers thereof (1203 in Fig. 12). 

(3) After recognizing the fact that three ack 

O 

v3 response packets are returned, the source node 302 

ru 

in 10 divides the object data 308 into predetermined pay load 
\H sizes on the basis of the sizes of the receiving 

Iff buffers of the ack response packets and successively 

p effects the broadcast until the buffer sizes of the 

\2 respective destination nodes 304 are obtained 1204 in 

% 15 Fig. 12). 

".cr 

''^ ( 4 ) In the last segment data of the all of the 

object data 308, the source node 302 sets a segment end 
flag indicating the end of the segment and sends it 
( 1205 in Fig. 12) . 

20 (5) When receiving the segment end packet, each 

destination node 304 returns segment end receive 
response, indicating the fact that the receiving of all 
of the object data 308 is completed (1206 in Fig. 12). 
( 6 ) After recognizing the fact that the segment 

25 end receive responses are returned from all of the 

destination nodes 304 the controller 300 and the source 
node 302 recognize the fact that the transferring of 
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the object data 308 is finished. 

Incidentally, the transfer model for the object 
data explained in connection with Fig. 12 can be 
represented in the similar manner as Fig, 7. 
5 Next, a communication sequence in a network in 

which three destination nodes 304 have difference size 
buffers will be fully explained with reference to Fig. 
13. In order to facilitate the explanation, it is 
assumed that the number N of the destination nodes 304 
10 is three (N = 3). In Fig. 13, the source node 302 has 
already been informed of the fact that there are thee 
destination nodes connected by the same connection ID, 
from the controller 300. 

( 1 ) When the transaction command from the 

15 controller 300 is sent to the source node 302, the 
source node 302 broadcasts the connection request 
packet in accordance with the sequences shown in Fig. 
4A (1301 in Fig. 13). 

(2) At the point that preparation of receiving is 
20 completed, the three destination nodes 304 return the 

ack response packets including the sizes of the 
receiving buffers thereof (1302 in Fig. 13). 

(3) After recognizing the fact that three ack 
response packets are returned, the source node 302 

25 divides the object data 308 into predetermined pay load 
sizes on the basis of the sizes of the receiving 
buffers of the ack response packets. And, the source 
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node successively effects the broadcast: until a minimum 
receiving buffer among the three destination nodes 304 
is filled, and is waiting for the receive response from 
the destination node 304 having the minimum buffer 
5 (1303 in Fig. 13) . 

(4) After receiving the receive response packet 
from the destination node 304 (Destination #1 in Fig. 
13) having the minimum buffer, the source node 302 
further effects the broadcast successively until the 

10 buffer size of a larger receiving buffer is obtained, 

and is waiting for the receive response packet from the 
next destination node 304 (1304 in Fig. 13). 

(5) After receiving the receive response packet 
from the second destination node 304, the source node 

15 302 further effects the broadcast successively until 
the buffer size of the largest receiving buffer is 
obtained, and is waiting for the receive response 
packet from the next destination node 304 (1305 in Fig. 
13). 

20 ( 6 ) After the above-mentioned sequences are 

repeated, the source node 302 broadcasts the last 
segment data in which the segment end flag is set and 
is waiting for segment end receive responses from the 
respective destination nodes 304 (1306 in Fig. 13). 

25 (7) After receiving the segment end receive 

responses from all of the destination nodes 304, the 
controller 300 and the source node 302 recognize the 
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fact that the transferring of the object data 308 is 
finished (1307 in Fig. 13). 

Next, a transfer model of the object data in Fig. 
13 will be explained with reference to Fig. 14. In 
5 order to facilitate the explanation, it is assumed that 
the number N of the destination nodes 304 is two (N = 
2). Incidentally, in Figs. 15A and 15B, while an 
example that the object data 308 of the source node 302 
U3 is a still image having data size of 128 Kbytes will be 

; E : 

5 *» 

iff 10 explained, the present invention is not limited to such 

I'y 

= n an example, but the data size is variable. Further, 

I'U 

\jk the object data 308 is not limited to the still image 

n but may be text data or binary data. 

hT When it is assumed that the pay load size of one 

? 15 asynchronous broadcast packet is 256 bytes, the source 

' y node 302 divides the object data 308 into 500 segment 

data and successively broadcasts the respective segment 
data until the buffer size of Destination #1 is 
obtained. After the receiving buffer is filled, the 
20 Destination #1 returns the receive response packet. 
The source node 302 further continues to broadcast 
successively until the receiving buffer of Destination 
#2 is filled. 

In this example, while the buffer size of the 
25 Destination #2 is twice of the buffer size of the 

Destination #1, the present invention is not limited to 
such an example. As mentioned above, in Figs. 15A and 
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15B, the Destination #1 returns three (in total) 
segment receive responses and the Destination #2 
returns two segment receive responses. 

Next, a transfer re-starting sequence in the 
5 asynchronous broadcast transaction between one source 
node 302 and a plurality of destination nodes 304 will 
be explained with reference to Figs. 15A and 15B. Fig. 
16 shows the restoring sequence particularly when the 
bus reset occurs. As mentioned above, the bus reset 

10 occurs in accordance with change in connecting 

structure and ON/OFF of power source of each node. 

For example, Figs. 15A and 15B show examples that 
the object data 308 of the source node 302 is received 
by three destination nodes 304. At the time when the 

15 source node 302 finishes to transfer the segment data 
having the sequence number i, if the bus reset occurs, 
the node on the bus initialize the network in 
accordance with the IEEE 1394-1995 Standard and 
automatically effect re-recognizing process. 

20 After the re-recognizing process for the bus is 

completed, each destination node 304 broadcasts resend 
request packet in which the connection ID and the 
sequence number of the segment data correctly received 
(before the bus reset occurs) are stored. For example, 

25 in Figs. 15A and 15B, the Destination nodes #1, #2 

could correctly receive the data having the sequence 
numbers up to i and Destination node #3 could correctly 
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receive the data having the sequence numbers up ti (i- 
1). Accordingly, the source node 302 starts the re- 
sending from the segment data having the sequence 
number i . 

In the illustrated embodiment, in case of Fig. 
15A, the source node 302 selects the minimum number 
((i-1) in this case) among the sequence numbers 
indicated by each resend request packet and starts the 
transferring from the segment data having sequence 
number i . 

Further, as shown in Fig. 15B, although the source 
node 302 receives each resend request packet, the 
source node can start the re-sending from the segment 
data having the sequence number 0 without 
discriminating the minimum sequence number. In this 
case, the function for discriminating the minimum 
sequence number can be omitted. 

In this way, when there are the plurality of 
destination nodes 304, even if the bus reset occurs, 
all of the destination nodes 304 can re-start the data 
transferring without loosing the object data. 
( Second Embodiment ) 

Now, a communication protocol according to a 
second embodiment of the present invention will be 
briefly described with reference to Fig. 16. 

In the above-mentioned first embodiment, the 
communication protocol in which the logical connection 
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relationships are set between the source node 302 and 
one or more destination nodes 304 by using the 
connection ID and communication between one source node 
302 and one destination node 304 is realized by using 
5 the connection ID and the asynchronous broadcast 
transaction was explained. 

In the second embodiment, a communication protocol 
in which communication between one source node 1602 and 
one or more destination nodes 1604 is realized by using 

10 the aforementioned connection ID and an asynchronous 
streaming packet based upon IEEE 1394-a Standard will 
be described. 

In this embodiment described hereinbelow, a 
transfer system in which a part or all of the object 

15 data 1608 (for example, still image data having one or 
more scenes, moving image data corresponding to 
predetermined time period, video data or text data 
corresponding to predetermined pages) is transferred by 
using an asynchronous streaming packet which will be 

20 described later is referred to as "asynchronous 
streaming transfer" . 

The asynchronous streaming transfer is carried out 
during the transferring period of the transfer system 
based upon the IEEE 1394-1995 Standard. Further, the 

25 asynchronous streaming transfer is adapted to be 
broadcasted on the communication system and is a 
communication system suitable for effecting the 
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communication between one equipment and a plurality of 
equipments . 

Similar to the isochronous transfer system, in the 
asynchronous streaming transfer, it is required that a 
predetermined channel number is set. Accordingly, in 
the illustrated embodiment, the channel number is set 
in each asynchronous streaming transfer by using 
isochronous response manager (referred to as "IRM" 
hereinafter) for managing the channel number used in 
the isochronous transfer system. 



V Now, in the illustrated yembodiment, as is in the 
first embodiment, for example, the computer having the 
1394 interface 14 will bor explained as a controller 
1600, the VDCR 28 havir*g the 1394 interface 44 will be 
explained as a source^ node 1602, and the printer 60 
having the 1394 interface 62 will be explained as a 
destination node &603 . Incidentally, in Fig. 2, while 
an example that /the communication system is constituted 
by three commimication apparatuses was explained, the 
present invention is not limited to such an example. 
For example, a communication system in which a 
plurality of computers 10, DVCRs 28 and printers 60 are 
connected may be used, and the communication apparatus 
constituting the destination node 1603 is not limited 
to c^rie. 

In Fig. 16, the reference numeral 1600 denotes a 
controller; 1602 denotes a source node; 1604 denotes a 
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destination node; 1606 denotes a submit in the source 
node; 1608 denotes object data such as image data; 1610 
denotes receiving FIFO in the destination node; 1612 
denotes first connection; 1616 denotes n-th connection; 
5 and 1620 denotes IRM. 

The controller 1600 is a node having a function 
for setting connection ID for establishing the 
connection between the source node 1602 and one or more 
destination nodes 1604 and for discriminating such 
1.0 10 connection. 

The controller 1600 may be a node independent from 
the source node 1602 and the destination node 1604. 
Alternatively, the source node 1602 or the destination 
node 1604 may be the same as the controller 1600. In 
15 the latter case, the transaction between the source 
node 1602 or the destination node 1604 and the 
controller 1600 can be omitted. As is in the first 
embodiment, in the illustrated embodiment, an example 
that the controller 1600 is a node different from the 
20 source node 1602 and the destination node 1604 is 
shown . 

In the communication apparatus according to the 
illustrated embodiment, a plurality of connections can 
be established. The controller 1600 sets the same 
25 channel number and connection ID in the source node 
1602 and the destination node 1604 selected by the 
user, by using an asynchronous packet. The source node 
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1602 writes the object: data 1608 such as image data 
from the internal subunit 1606 on the first receiving 
FIFO 1610 within the destination node by using the 
asynchronous streaming packet, for example, through the 
5 first connection 1612. 

The asynchronous streaming packet used in this 
case is sent by the channel number designated by the 
controller 1600. The connection ID set by the 
5 : y controller 1600 is stored in the pay load of this 

ifl 10 packet as a part of data header information. 

* LI 

=n When receiving the asynchronous streaming packet 

IP, having the channel number designated by the controller 

i'3 1600, the destination node 1604 stores such packet in 

■T the receiving FIFO 1610 temporarily and analyzes the 

'% 15 data header information during pay load. When this 

receiving packet has the connection ID designated by 
the controller 1600, the data from which the data 
header information is written in the internal buffer. 

Also when there are plurality of destination nodes 
20 1604, since each node can discriminate the 

predetermined connection by using the channel number 
and the connection ID, the source node 1602 can 
transfer the data to the plurality of destination nodes 
1 604 simultaneously . 
25 Next, a construction of the communication packet 

used in the second embodiment will be explained with 
reference to Figs. 17A and 17B. The communication 
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packet used in this embodiment is, for example, a 
packet having a unit of 4 bytes (32 bits; referred to 
as "quadlet" hereinafter). In this communication 
packet, there are two formats, i.e., a packet of a type 
5 in which designating the node ID of the receiver (i.e., 
asynchronous packet ) and a packet of a type for 
designating and broadcasting the channel number called 
as asynchronous streaming. 

The packet format shown in Fig. 17A is of the type 
\fl 10 for designating the node ID. As shown in Fig. 17A, a 

first field 1701 (16 bits) is a destination_ID field 

12 into which the node ID of the receiver is stored. 

y 1 

L, A next field 1702 (6 bits) is a transaction label 

|W ( tl ) field which is a tag inherent to each transaction. 

15 A next field 1703 (2 bits) is a retry (rt) code 

*,B which designates whether the packet tries to retry or 

not . 

A next field 1704 (4 bits) is a transaction code 
( tcode ) . The tcode designates the type of the 

20 transaction to be executed and the format of the 

packet. In the illustrated embodiment, for example, 
this value is set to 0001 (binary scale). Thus, the 
transaction for writing the data block is requested. 
A next field 1705 (4 bits) is a priority (pri) 

25 field for designating the preferential order. In the 

illustrated embodiment, a value of this field is set to 
0000 (binary scale). 
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A next field 1706 (16 bits) is a source_ID field 
indicating node ID of the sender side. A next field 
1707 (48 bits) is a destination_of f set field for 
designating lower 48 bits for the address space of 64 
bits of the destination node 1604. 

A next field 1708 (16 bits) is a data_length field 
indicating a length of a data field (described later) 
as a byte unit. 

A next field 1709 (16 bits) is an extended_tcode 
field. When the transaction for writing the data block 
used in the illustrated embodiment is requested, a value 
of this field is set to 0000 (16 scale). 

A next field 1710 (32 bits) is a header_CRC field 
which is used for detecting an error of the packet 
header. The packet header is constituted by the fields 
1701 to 1709. 

A next field 1711 is a data field having a 
variable length, and this data field is referred to as 
"pay load". In the illustrated embodiment, when this 
data field is not multiple of the quadlet, bits shorter 
to the quadlet are filled with "0". 

A next field 1712 (32 bits) is a data_CRC field 
which is used for detecting an error of the data field, 
similar to the header_CRC field. 

The packet format shown in Fig. 17B is format for 
a packet of a type designating the channel number 
(i.e. , asynchronous streaming packet ) . 
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As shown in Fig. 17B, a first field 1720 (16 bits) 
is a data_length field indicating a length of a data 
field (described later) as a byte unit. 

A next field 1721 (2 bits) is a tag field, and a 
5 value of this field is 00 (binary scale). 

A next field 1722 (6 bits) is a channel field 
indicating the channel number of this packet. The 
receiving node discriminates the packet by using this 
fc 3 channel number . 

l~ 10 A next field 1723 (4 bits) is a transaction code 

;^ (tcode). In the asynchronous streaming packet, a value 

j|~ of this field is A (16 scale). 

A next field 1724 (4 bits) is a synchronization 
I'U code (sy) field, and a value of this field is 

hB 15 determined by application using this packet. 

=U A next field 1725 (32 bits) is a header_CRC field 

which is used for detecting an error of the packet 
header. The packet header is constituted by the fields 
1720-1724. 

20 A next field 1726 is a data field having a 

variable length, and this field is referred to as "pay 
load" . In the illustrated embodiment, when this data 
field is not multiple of the quadlet, bits shorter to 
the quadlet are filled with "0" . A next field 1727 (32 

25 bits) is a data_CRC field which is used for detecting 

an error of the data field, as is in the aforementioned 
header CRC field. 
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Next , the asynchronous transaction ef f ected 
between the controller 1600, source node 1602 and 
destination node 1604 shown in Fig, 16 and the IRM 
(node becoming isochronous resource manager) not shown 
5 in Fig. 16 will be explained with reference to Figs. 18 
and 19. Incidentally, in the following explanation, 
regarding Fig. 18, a sequence in which the connection 
is set between one source node 1602 and one destination 

g node 1604 will be described, and, regarding Fig. 19, a 

y 

n 10 sequence in which the connection is set between one 
« source node 1602 and a plurality of destination nodes 

S 1604 will be described. 

™ The controller 1600 issues (read transaction) a 

y read request packet to a CH ANNE LS_AVA I LAB LE register of 

3 15 the IRM 1620. When receiving the packet, the IRM 1620 

ij 

J3 sends the contents of the CHANNE LS_AVA I LABLE register 

to the controller 1600 as read response (1801 in Figs. 
18 and 19 ) . Usage conditions of the channels at that 
point are set in this register, so that, by checking 
20 the data, non-used channels can be known. The 

controller 1600 selects one channel among the non-used 
channels . 

Then, the controller 1600 issues (write 
transaction) set-up command for setting the connection 
25 to the source node 1602. The channel number selected 

by the controller 1600 and the connection ID controlled 
by the controller 1600 itself are written in this set- 
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up command. When receiving -the set: -up command, the 
source node 1602 sends a response packet for the set-up 
command to the controller 1600 (1802 in Figs. 18 and 
19). 

5 The source node 1602 to which the channel number 

was informed from the controller 1600 issues (read 
transaction) the read request: packet to the 
CHANNELS_AVAILABLE register of the IRM 1620. When 
receiving the packet, the IRM 1620 sends the contents 

si I 

10 of the CHANNELS_AVAILABLE register to the source node 
8 £ 1602 as read response (1803 in Figs. 18 and 19). 

The source node 1602 sends a compare & swap lock 
* request packet to the IRM 1620 by using this response 

lU data. This lock packet is a packet for rewriting the 

U3 15 contents of the CHANNELS_AVAILABLE register informed 

s ! H 

i,3 from the controller 1600 (i.e., making the channel 

informed from the controller 1600 under usage). When 
the lock transaction becomes successful, the channel is 
ensured. The IRM sends the response packet for lock 
20 request to the source node 1602 (1804 in Figs. 18 and 
19). 

Pursuant to the source node 1602, the controller 
1600 sends (write transaction) set-up command for 
setting the connection to the destination node 1604. 
25 The channel number informed to the source node 1602 and 
the data same as the connection ID are written in the 
set-up command. The destination node 1604 sends the 
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response packet for -the set-up command (1805 in Fig. 

18) . 

Further, as shown in Fig. 19, when there are a 
plurality of destination nodes 1604, the set-up command 
5 is successively transferred to the respective 

destination nodes, thereby effecting set-up (1901 in 
Fig. 19). 

By the above-mentioned sequences, the controller 
.J 1600 can set the common asynchronous stream channel and 

iS 10 the common connection ID between the source node 1602 

and the destination node 1604, thereby establishing the 
;~ theoretical connection between the respective nodes. 

v.? I 

!!_ Then, the controller 1600 sends (write 

transaction) data receiving command to the destination 
*=5 15 node 1604, The destination node 1604 which received 
=0 this command prepares the receiving of data and sends 

the response packet to the controller 1600 (1806 in 
Fig. 18). As shown in Fig. 19, when there are a 
plurality of destination nodes 1604, the data receiving 
20 command is successively sent to the respective 

destination nodes. As a result, the destination nodes 
1604 become a receive waiting condition (1902 in Fig. 

19) . 

After the destination nodes become the receive 
25 waiting condition, the controller 1600 sends (write 
transaction) data sending command to the source node 
1602. When receiving this command, source node 1602 
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10 



15 



20 



25 



sends the response packet: to the controller 1600 (1807 
in Figs. 18 and 19). The above-mentioned transaction 
is effected by using the asynchronous packet shown in 
Fig. 17A. 

An example of data format of the command used in 
the set-up command, data receiving command and data 
sending command is shown in Fig. 20. After the command 
shown in Fig. 20 is set in the data field 1711 shown in 
Fig. 17A, the command is sent to the respective nodes 
by using the write transaction. 

In Fig. 20, a type field 2001 indicates the kinds 
of commands. The following Table 1 shows several types 
of commands. 

Table 1 



value 


command type 


meaning 


0 


Control 


control command 


1 


Status 


query of equipment conditions 


2 


Inquiry 


query of support condition of 
command 


3 


Notify 


recognition of change in 
equ i pmen t cond i t i ons 



The above-mentioned commands designate the Control 
in the Table 1. A subunit_type field 2002 and a 
subunit ID field 2003 are fields indicating which 
command of unit in the node designated by the packet 
header is included in this packet. An opcode field 
2004 and operand fields 2005-2011 are fields indicating 
the contents of the actual command. 
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Fig. 21 shows an example of data format of 
response for the above-mentioned commands. The 
response shown in Fig, 21 is sent to the respective 
nodes after it is set in the data field 1711 shown in 
5 Fig. 17A. 

In Fig. 21, a response field 2101 indicates the 
kinds of responses. The following Table 2 shows 
several types of responses. 

Table 2 



value 


response type 


meaning 


8 


Not implemented 


command is not supported 


9 


Accepted 


command was accepted 


A 16 


Re j ected 


command is rejected 


Fie 


Interim 


return response later 



U 15 

A subunit_type field 2102 and a subunit ID field 
" ,i=? 2103 are fields indicating the unit in the node from 

which the response is send. An opcode field 2104 and 
operand fields 2105-2111 are fields indicating the 
20 contents of the response. 

For example, when the node which received the 
above-mentioned command from the controller 1600 
receives the command, the node transfers a response 
packet in which "Accepted" is set in the response field 
25 2101 to the controller 1600 by using the write 
transaction . 

In Figs. 18 and 19, the source node 1602 which 
received the data sending command divides the 
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previously selected object data 130S into a plurality 
of segment data and successively transfers the segment 
data (1808 in Figs. 18 and 19). The segment data are 
transferred by using the asynchronous streaming packet 
5 shown in Fig. 17B. In this case, the ensured channel 
number is written in the channel field shown in Fig. 
17B is set by using the IRM. 

Next, a sequence for dividing the object data 1608 
and for successively transferring the divided data will 

10 be explained with reference to Fig. 22. 

In the source node 1602, the object data 1608 
having an image size of 128 KB has been selected in 
accordance with the above-mentioned communication 
sequence. The source node 1602 divides the object data 

15 1608, for example, into 512 segments (1 segment = 256 
bytes ) and transfers the segments to one or more 
destination nodes 1604 by the asynchronous streaming 
transfer using the predetermined channel. 

As shown in Fig. 22, the destination node 1604 

20 takes the asynchronous streaming packet having the 
predetermined channel into its FIFO 1610 and 
discriminates whether it includes the set connection ID 
by checking the pay load of the packet. If the 
connection ID is included, the segment data included in 

25 the packet are successively stored in the internal 

buffer, and the object data 1608 from the source node 
1602 is received. 



- 71 - 



Fig. 23 shows an example of data format for a part 
(i.e., 1 segment data) of the object data 1608 to be 
set in the data field 1726 shown in Fig. 17B. 

In Fig. 23, a first one quadlet constitutes a 
5 header field 2301 (referred to as "stream info header" 
hereinafter). A control_f lags field 2302 indicates the 
kind of data sent by this packet. The following Table 
3 shows examples of the control_f lags . 

For example, in Fig. 22, "normal segment data" 
10 shown in the Table 3 is set in a packet for sending 
segment 0 - segment 510, and "segment data of object 
end" shown in the Table 3 is set in a packet for 
transferring segment 511 which is last data of the 
object data 1608. 
15 Table 3 



value 


meaning 


oo 16 


normal segment data 


oi 16 


segment data of object end 



20 The connection ID set by the controller is set in 

a connection_ID field 2303. Further, the divided 
object data 1608 (i.e., 1 segment data) is set in a 
segmented object data field 2304. 

In case of the example shown in Fig. 22, the 

25 stream info header (4 bytes) and the segment data (256 
bytes) (i.e., 260 bytes in total) constitute the pay 
load of one asynchronous streaming packet. The 
respective packets are successively transferred from 
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the source node 1602 by using the channel number set by 
the aforementioned communication sequence. 

When receiving the asynchronous streaming packet, 
each destination node 1604 checks the channel field 
5 1722 of the packet header and judges whether the 
channel field coincides with the channel number 
informed from the controller or not. If the channel 
field coincides with the channel number, this packet is 
taken into the receiving FIFO 1610. 

10 Further, each destination node 1604 judges whether 

the value of the connect ion_ID field of the stream info 
header 2301 of the taken packet coincides with the 
connection ID informed from the controller 1600 or not. 
If coincides, each destination node 1604 writes the 

15 segment data 2304 (except for 4 bytes of the stream 
info header 2301) in the internal buffer. Further, 
each destination node 1604 checks the control_f lags 
field 2302 of the stream info header 2301 and judges 
whether this segment data is the last data of the 

20 object data 1608 or not. 

In case of the example shown in Fig. 22, from 
start of the data transferring, "segment data of object 
end" is set in the control_f lags field 2302 of the 
stream info header 2301 of the 512-th asynchronous 

25 streaming packet. At the time when the destination 
node 1604 writes the segment data included in this 
packet in the internal buffer, the transferring of the 
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object data 1608 is finished. 

Next, a flow of the data transfer 1808 shown in 
Fig. 19 will be fully explained with reference to Fig. 
24. For example, when each segment data shown in Fig. 
5 22 is transferred, the source node 1602 sets one 

segment data (as well as header information) in the pay 
load of the asynchronous streaming packet and transfers 
the data by using the predetermined channel . 
,g In this case, the connection ID informed from the 

10 controller 1600 is set in the connection_ID field 2303 
3 J of the header information within the pay load and 

IjE values shown in the flow of Fig. 24 are set in the 

control_f lags field 2302. When the segment 511 (last 
]^ data) is transferred, "01h" indicating "segment data of 

15 object end 11 is set in the control_f lags field 2302. 

. Fx, 

v3 Each destination node 1604 receives the 

asynchronous streaming packet having the channel number 
informed from the controller 1600 and recognizes the 
contents of the header information in the pay load. 

20 When the connection ID coincides with the connection ID 
set in itself, the segment data are taken from the 
packet and are stored in the internal buffer 
successively . 

When the control_f lags field 2302 receives the 

25 asynchronous streaming packet having "Olh", each 
destination node 1604 detects the fact that the 
receiving of the object data 1608 is completed and 
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finishes the receiving operation. Each packet shown in 
Fig. 24 is broadcasted from the source node 1602 only 
once by the asynchronous streaming transaction. The 
plurality of destination nodes 1604 connected to the 
5 source node 1602 by the theoretical connection receive 
the packets simultaneously. 

Further, when there is only one destination node 
1604, the destination nodes 1604 shown in Fig. 24 is 
merely reduced to one, and the flow of the data 

10 transfer 1808 is the same as when there are the 
plurality of destination nodes. 

In this way, by setting the same channel number 
and connection ID in one or more destination nodes 1604 
and the source node 1602 by means of the controller 

15 1600, the theoretical connection can be set between the 
source node 1602 and one or more destination nodes 
1604. Further, the data transferring process can be 
effected by the transaction only between the source 
node 1602 and the destination node 1604 without 

20 presence of the controller 1600. 

Particularly, by informing one source node 1602 
and the plurality of destination nodes 1604 of the same 
channel number and connection ID, the theoretical 
connections having a ratio of 1:N can be set, and the 

25 data communication having a ratio of 1:N can be 

performed by using the same sequence as the ratio of 
1:1. 
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Further, even when -there are the plurality of 
destination nodes 1604, each segment is not required to 
be sent to each destination node independently, thereby 
reducing the traffic on the bus* 
5 ( Third Embodiment ) 

In a third embodiment of the present invention 
which will be described hereinbelow, a system and a 
communication protocol for transferring the object data 

P 

1608 to the destination node 1604 more positively by 
Ifi 10 using the above-mentioned asynchronous streaming 

transfer is disclosed. Since a sequence in which the 
!^ controller 1600 sets the theoretical connection between 

the source node 1602 and the destination node 1604 is 
iU the same as that (Figs, 18 and 19) in the second 

v5 15 . embodiment, detailed explanation thereof will be 

\.Q omitted. 

As is in the second embodiment, also in this 
embodiment, a case where the object data 1608 in Fig. 
22 is transferred from the source node 1602 to the 
20 destination node 1604 will be described. 

Fig. 25 shows an example of format for an 
application header to be stored in the asynchronous 
streaming packet in this embodiment. In the following 
explanation, this header is referred to as "common 
25 asynchronous streaming header" and is called as "CAP 

header" hereinafter. The CAP header is variable length 
data having a unit of 1 quadlet (32 bits). 
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In Fig. 25, a field 2501 is E0H_n (end of CAP 
header) indicating whether or not the CAP header having 
n-th quadlet is the last quadlet. For example, "0" 
indicates that this quadlet is followed by another 
5 quadlet data; whereas, 1 indicates that this quadlet 
is the last of the CAP header. A field 2502 is Form_n 
indicating a structure of CHF_n in combination with 
EOH . A field 2503 is CHF_n (CAP header field) having a 
structure depending upon a value of Form and EOH. 

10 In the illustrated embodiment, as shown in Fig. 

26, the CAP header is stored in the first one quadlet 
of the pay load of each asynchronous streaming packet, 
and the segment data are stored in the second, third 
and so on quadlets. In Fig. 26, E0H_0 = 1 and Form_0 = 

15 0. 

A connection_ID field 2303 and a control flags 
field 2302 shown in Fig. 25 are the same as those in 
the second embodiment. A sequence number field 2601 
indicates serial numbers of the segment data sent by 

20 this packet. For example, as shown in Fig. 22, when 

the segment 0 is transferred, "0" is set in the segment 
number field 2601; whereas, when the segment 1 is 
transferred, "1" is set in the segment number field. 
As is in the second embodiment, divided object data are 

25 set in the segmented object data field 2304. 

Next, the data transfer according to the 
illustrated embodiment will be fully explained with 
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reference to Fig. 27. In Fig. 27, as shown in Fig. 26, 
each segment data is set in the pay load of the 
asynchronous streaming packet together with the CAP 
header and is transferred from the source node 1602 by 
5 using the predetermined channel number. In this case, 
the connection ID informed from the controller 1600 is 
set in the connect ion_ID field 2303 of the CAP header 
and values shown in Fig. 27 are set in the control 
flags field 2302 and the sequence number field 2601. 

10 When the segment 511 (last data) is sent, "01h" 

indicating 11 segment data of object end" is set in the 
control_f lags field 2302. 

The destination node 1604 receives the 
asynchronous streaming packet having the channel number 

15 informed from the controller 1600 and recognizes the 
contents of the CAP header. Further, the destination 
node judges whether the contents coincide with the 
connection ID set in itself. If coincide, the contents 
are successively stored in the internal buffer. When 

20 the control_f lags - field 2302 receives the asynchronous 
streaming packet having "01h", the destination node 
1604 sends the response packet indicating the fact that 
the receiving of the object data 1608 is completed, by 
using the asynchronous streaming transfer. Fig. 28 

25 shows an example of format for this packet. 

Fig. 28 is a view showing a construction of the 
data field 1726 of the response packet. The cap header 
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having one quadlet amount: is set: in this packet:. The 
channel number in this case is the same as the channel 
number used by the source node 1602 to transfer the 
object data 1608, and the connection_ID within the CAP 
5 header is also the same as the connection ID used by 

the source node 1602 to transfer the object data 1608. 

The data indicating the kind of response is stored 
in the control_f lags field 2302. The following Table 4 

O 

%i q shows examples of the kinds. When all of the object 

iS 10 data 1608 are received correctly, "lOh" indicating 

*S "sequence number" is set. Further, when receiving 

: J correctly, the sequence number of the last data is set 

|L in the sequence number field 2601. 

= ^ Table 4 



value 


meaning 


io 16 


receive success 


Hl6 


resend request 



When the source node 1602 transfers the last data 
20 of the object data 1608, the source node is waiting for 
response from the destination node 1604. When the 
asynchronous streaming packet having the same channel 
as the channel number used for transferring the object 
data 1608 is received, the source node 1602 checks the 
25 CAP header in this packet and judges whether the object 
data 1608 is correctly received or not, and the 
transferring the object data 1608 is finished. 

Next, a flow if any error occurs during the 



# • 

- 79 - 



-transferring of the object data 1608 will be explained 
with reference to Fig. 29. After the connection is set 
in the similar sequence to the second embodiment, the 
source node 1602 starts the transferring of the object 
5 data 1608 (2901 in Fig. 29). If the segment n could 
not received by the destination node 1604 for any 
reason (2902 in Fig. 29), at the time when the segment 
(n+1) is received, the destination node 1604 detects 
the fact that the segment n is lost (2903 in Fig. 29). 

Ifl 10 At this point, the destination node 1604 sends the 

response packet requesting the resend of the segment n 

\& to the source node 1602 by using the asynchronous 

streaming transfer (2904 in Fig. 29). 

=- The format for this packet is the same as the 

■|f 15 above-mentioned response packet and is transferred by 

s ! E 

Ui using the same channel number and connection ID as 

those used by the source node 1602. "llh" indicating 
"resend request" is set in the control_f lags field 2302 
within the CAP header, and the sequence number 

20 corresponding to the segment data which could not be 
received is set in the sequence number field. 

When the source node 1602 receives the 
asynchronous streaming packet having the channel same 
as the channel number used for transferring the object 

25 data 1608, the source node 1602 checks the CAP header 
within the packet. When it is recognized that this 
packet is the response requesting "resend request", the 
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source node 1602 starts the re-sending from the segment 
data corresponding to the designated sequence number 
(2905 in Fig. 29 ) . In a subsequent data transferring 
flow, the transferring is effected in accordance with 
the aforementioned sequence. 

Next, a flow if the bus reset occurs during the 
transferring of the object data 1608 will be explained 
with reference to Fig. 30. After the connection is set 
in the similar sequence to the second embodiment, the 
source node 1602 starts the transferring of the object 
data 1608 (3001 in Fig. 30). If the bus reset occurs 
after the transferring of the segment n, the nodes on 
the bus effect initialization and re-construction of 
the bus in a predetermined sequence (3002 in Fig. 30). 

When the re-construction of the bus is finished, 
the source node 1602 and the destination node 1604 re- 
start the object data before the bus reset occurs, by 
using the channel number and connection ID set by the 
controller 1600 before the bus reset occurs. In this 
case, the source node 1602 re- starts the data sending 
from the segment data pursuant to the segment data sent 
before the bus reset occurs (3003 in Fig. 30). 

When the segment data received after the bus reset 
occurs is data pursuant to the segment data received 
before the bus reset occurs, the destination node 1604 
continues the receiving. However, if the segment data 
prior to the segment data received after the bus reset 
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occurs is not received correctly, similar to the 
sequence shown in Fig. 29, the response packet 
requesting the re-sending of the segment n is 
transferred (3004 in Fig. 30). The source node 1602 
5 starts the data transferring again from the segment n. 
In a subsequent data transferring flow, the 
transferring is effected in accordance with the 
aforementioned sequence (3005 in Fig. 30). 

In this way, by providing the header within the 

10 pay load to add the information of the segment data, 
the data communication can be effected positively by 
using the asynchronous streaming transfer, and, even if 
the error and/or the bus reset occur, the object data 
can be transferred to one or more destination nodes 

15 1604 without loosing the data. 

As mentioned above, in the above-mentioned 
embodiments, the logical connection relationship not 
depending upon the physical connecting styles can be 
formed within the network of bus type such as 

20 stipulated in the IEEE 1394-1995 Standard. 

Further, according to the illustrated embodiments, 
in the communication system based upon the IEEE 1394- 
1995 Standard, there can be provided a new 
communication protocol in which a relatively large 

25 amount of object data (for example, still image data, 
graphic data, text data file data, program data or the 
like) not requiring the real time ability but requiring 
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the responsibility is divided into one or more segment 
data which are in turn transferred continuously. 

In addition, according to the illustrated 
embodiments, in the communication system based upon the 
5 IEEE 1394-1995 Standard, there can be provided a new 

communication protocol for realizing data communication 
between a plurality of equipments by using a 
communication system for broadcasting the data 
iO asynchronous transferring. 

Ifi 10 Further, according to the illustrated embodiments, 

{j'jj S 

a plurality of data having continuity can positively be 
J- transferred without using the isochronous transfer 

Hi? I 

L system based upon the IEEE 1394-1995 Standard. In 

; y addition, one object data can be transferred positively 

15 by dividing the object data into a plurality of data. 
Furthermore, according to the illustrated 
embodiments, by controlling the communication between a 
plurality of equipments by one connection, many 
communications can be achieved simultaneously without 
20 using communication band not so much. 

Lastly, according to the illustrated embodiments, 
even if the data transferring is interrupted due to 
occurrence of the bus reset or communication error, it 
is possible to know which segment data is lost, and the 
25 transferring can be re-started without complicated 
communication sequence . 
( Other Embodiments ) 
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The protocols explained in -the illustrated 
embodiments and various processing operations required 
for realizing the protocols can be effected by 
software. 

5 For example, a recording medium storing program 

code for realizing the functions in the illustrated 
embodiments is supplied to a control unit (for example, 
system controller 50, printer controller 68 or MPU 12 

,g in Fig. 2 ) of the equipments constituting the 

Tl I 

10 communication protocol according to the illustrated 

y i 

S J: embodiments. And, when the control unit is designed to 

:z read-out the program code stored in the recording 

Ifl 

medium and control the operation of the communication 
t'U system or the equipment itself to realizing the 

U3 15 functions according to the illustrated embodiments, 

v3 such embodiments can be performed. 

Further, a recording medium storing program code 
for realizing the functions in the illustrated 
embodiments is supplied to the 1394 interfaces 14, 44, 
20 62 of the equipments so that a control unit (for 
example, serial bus management 806 in Fig. 8) for 
controlling the operation of the 1394 interfaces 14, 
44, 62 may control the processing operations to realize 
the functions in the illustrated embodiments in 
25 accordance with the program code stored in the 
recording medium. 

In this case, the program code itself read-out 
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from -the recording medium realizes the functions in the 
illustrated embodiments, and the program code itself 
and a means (for example, recording medium itself) for 
supplying the program code to the control unit 
constitute the present invention . 

The recording medium for storing such program code 
may be, for example, a floppy disc, a hard disc, an 
optical disc, a photo-magnetic disc, CD-ROM, a magnetic 
tape, a non-volatile memory card or ROM* 

Further, it should be noted that the present 
invention includes a case where the program code read- 
out from the recording medium cooperates with an OS 
(operating system) or various application software to 
realize the functions in the illustrated embodiments. 

Lastly, it should be noted that the present 
invention includes a case where, after the program code 
read-out from the recording medium is stored in a 
memory of a function expanding unit connected to the 
control unit, a control unit of the function expanding 
unit performs a part or all of the actual process in 
accordance with the program code, stored in the memory 
to realize the functions in the illustrated 
embodiments . 

The invention may be embodied in other specific 
forms without departing from the spirit and essential 
characteristics thereof - 

For example, in the illustrated embodiments, while 
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an example that the communication protocol can be 
applied to the network based upon the IEEE 1394-1995 
Standard was explained, the present invention is not 
limited to such an example. The communication protocol 
5 according to the illustrated embodiment can be applied 
to a network of bus type such as stipulated in the IEEE 
1394-1995 Standard or a network imaginarily 
constructing a network of bus type* 

Therefore, the above-mentioned embodiments are 

10 merely examples in all respects, and must not be 
construed to limit the invention. 

The scope of the present invention is defined by 
the scope of the appended claims, and is not limited at 
all by the specific descriptions of this specification. 

15 Furthermore, all the modifications and changes 

belonging to equivalents of the claims are considered 
to fall within the scope of the present invention. 



